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Dear Sir: 

This is a Reply to the Examiner's Answer dated November 30, 2004 
provided in response to the Appeal Brief filed on behalf of the Appellant on 
August 17, 2004, which was filed to appeal the decision of the Examiner in the 
Final Office Action dated February 27, 2004 of claims 1-29. 



(1) HIGGINS DOES NOT TEACH OPERATING A NODE AS A PASS 
TRHOUGH FOR ATM TRAFFIC AS CLAIMED 

Independent claims 1 and 14 recite, in part, "operating the given node as 
a pass through for ATM traffic on other existing virtual path connections on 
the ring before a virtual path is established for the given node" (emphasis 
added). Independent claim 24 similarly recites, in part, "instruct[ing] a newly- 
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inserted node to operate as a pass through [for] ATM traffic via [preexisting] 
virtual paths until one or more new virtual paths are established for the newly- 
inserted node."i In other words, the claims require that a node operate to pass 
through ATM traffic, i.e., data transferred in ATM cells, for other virtual paths 
before a virtual path is established for the node. 

A. EXAMINER ASSERTS THAT APPELLANT MISINTERPRETS HIGGINS 

The Examiner asserts that Appellant has misinterpreted the phrase to 
and from the inter-nodal network in col. 4, lines 44-45 to mean that the newly 
added node 6c (hereafter "new node") cannot pass through packets already on 
the inter-nodal network from one neighbor node through the new node to 
another neighbor node (Exr. Ans. at page 10). The Examiner asserts that 
Higgins clearly discloses that the new node, once physically connected, can in 
fact pass through traffic already on the inter-nodal network (id.) 

In support of this position, the Examiner cites Higgins at col. 4, lines 35- 
43, which states, "[ajfter the two neighbor nodes return to open mode... a final 
verification is performed to ascertain that the new node or nodes as well as the 
neighbor nodes have open ports." [see Exr. Ans. at 10-11). The Examiner 
asserts this passage indicates that the nodes neighboring the newly added 
nodes (hereafter "neighbor nodes") return to open mode before final verification 

* Due to a typographical error, the relevant feature in claim 24 recites "instruct the newly-inserted node to operate as 
a pass through from ATM traffic..." (emphasis added). Appellant intended for this feature to recite "instruct the 
newly- mserted node to operate a pass through for ATM traffic..." It is respectfully submitted that, during 
prosecution, the Examiner interpreted this feature in claim 24 as intended by Appellant. This is evident from the 
final Office Action in which the Examiner applied the same grounds of rejection for claims 1, 14, and 24 (see Paper 
No. 6 at page 4). 
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(id. at 11). In page 11 of the Examiner's Answer, the Examiner further asserts 

that Higgins defines the open mode in col. 6, lines 62-65: 

In open operating mode, each of the nodes 6a through 6c receives 
packetized information through port A and transmits packetized 
information to the other nodes through port B as indicated by the 
solid arrows [referring to Fig. 2], 

The Examiner further asserts that, in light of this passage in Higgins, the "open 
operating mode" is justly equated with the "pass through" operation of the 
present invention. 

The Examiner further refers to the process of returning the neighboring 
nodes from loopback mode to open mode, and bringing the new node into 
service, as described in Higgins at col. 10, line 49 - col. 11, line 45 (Ex. Ans. at 
11-12). The Examiner particularly cites col. 11, lines 18-21, which discloses 
that, each of the neighbor nodes receives the EXPNTK_COMPLETED message 
after their I/O ports are open, thereby verifying that the inter-nodal network is 
intact (Ex. Ans. at 11). Presumably, the Examiner cites this portion of Higgins 
to show that the EXPNTK_COMPLETED message traveled from one of the 
neighbor nodes to the other by passing through the ports of the new node. 

Thus, the Examiner concludes that the new node acts as a pass through 
for ATM traffic before the final verification, which causes the new node to 
transition to RUNNING STATE. See Ex. Ans. at 12. The Examiner implicitly 
argues that transitioning of the new node is only required for allowing the new 
node to make its own connections. See Ex, Ans, at 1 1, 
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B. APPELLANT'S INTERPRETATION OF HIGGINS IS CORRECT 

1. HIGGINS'S MESSAGES ARE DIFFERENT THAN PACKETS 
Initially, Appellant respectfully disagrees with the Examiner's assertion 
that Appellant misinterpreted the phrase to and from the inter-nodal network. In 
col. 4, lines 35-47, Higgins discloses that the new node is configured to 
transmit and receive packets after acknowledgement is received. The Examiner 
is attempting to equate the control messages (e.g., EXPNTK_COMPLETED) 
disclosed in Higgins with these packets. This interpretation is not supported 
by the disclosure in Higgins, which consistently distinguishes the term 
messages from packets and packetized information. See, e.g., col. 2, line 66 - 
col. 3, line 11; col. 3, lines 51-63; col. 4, lines 1-4 and 35-40. 

Specifically, Higgins uses the term messages to refer to control messages 
(EXPNTK_COMPLETED, LOOPBK_COMPLETED, etc.) that are used to direct 
the nodes to perform various control functions. Such messages are either 
transmitted from a host to one of the nodes as Application Program Interface 
(API) messages from the host to a node, or transmitted from node to another via 
the control word 64. See col. 7, lines 31-39; col. 8, lines 6-20. On the other 
hand, Higgins uses packetized information to refer to traffic associated with 
networks, e.g., voice, data, video, and multimedia information. See col. 1, lines 
61-65. 

Furthermore, Higgins teaches that the control word 64 (which conveys 
the messages) is distinct from the packets 54, 58, 60. See col. 7, lines 31-49. 
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Specifically, the control word 64 is at the beginning of the frame, and the 
packets 54, 58, 60 follow. Id, 

Thus, the Examiner's attempt to equate the passing of messages (e.g., 
EXPNTK_COMPLETED) in Higgins with the passing of packets is not supported 
by the teachings of Higgins. 

2. HIGGINS'S MESSAGES DO NOT CONSITUTE NETWORK TRAFFIC 
Furthermore, Higgins specifically distinguishes the control messages 

from network traffic. In col. 4, lines 1-5, Higgins states: 

...the new node follows a sequence of instructions, triggered by 
certain host-issued messages, which causes the node to wait while 
the inter-nodal network, which continues to carry normal traffic, 
is configured to include the new node. 

Also, Higgins discloses that the packets — not the messages (control word) — 

convey data. In col. 7, lines 39-49, Higgins states: 

Each packet 54, 58, 60 contains a start-of-packet (SOP) entity 66, 
a source address (SRC) 68, ...a destination address (DST) 
70... Following these entities is a payload 72... An end-of-packet 
(EOF) entity 74 follows the payload 72. 

Accordingly, the packets 54, 58, 60 of the frame contain the payload or data — 
not the messages in the control word 64. Thus, it is clear that Higgins' s 
disclosed messages, such as EXPNTK_COMPLETED, do not contain network 
traffic. 

3. HIGGINS'S NEW NODE DOES NOT PASS PACKETS OR TRAFFIC 

Furthermore, during the process of bringing the new node 6d into service 
and returning the neighbor nodes 6a and 6c to open mode, Higgins only 
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discloses that messages are passed along the inter-nodal network. See col. 10, 
line 43 - col. 11, line 45. There is simply no disclosure in Higgins that any 
packets, i.e., traffic, are conveyed over the network during this process. In fact, 
the Examiner relies on Higgins's teaching that a message 
(EXPNTK_COMPLETED) is received by the neighbor nodes 6a and 6c to argue 
that the new node 6d operates as a pass through {see Ex. Ans. at 11). 
Appellant respectfully submits that the Examiner has provided no teaching in 
Higgins that a packet is conveyed on the inter-nodal network from the time the 
neighbor nodes are switched from loopback mode to open mode, until the time 
the new node enters into full service, i.e., RUNNING state 116. 

However, the Examiner nevertheless argues that col. 6, lines 62-65, of 
Higgins teaches that open mode is justly equated with "pass through" 
operation. Appellant respectfully submits that the Examiner misconstrues this 
section to mean that any node operating with open ports must be passing 
through packetized information. Instead, Appellant submits that the purpose of 
col. 6, lines 62-65, is to distinguish the ways in which a node's I/O ports 
convey packets in open operating mode and loopback operating mode. See col. 
5, line 59 - col. 7, line 20. In other words, this section teaches that, for 
situations where packets are transmitted through the inter-nodal network, a 
node in open mode will receive the packet in I/O port A and transmit the 
packet from I/O port B, while a node in loopback mode will both receive and 
transmit the packet using port B. See id,; Fig. 2, This section does not disclose 
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that a node must be passing through such packets simply because it has open 
ports. 

The Examiner also argues that col. 9, lines 36-42, demonstrates the 

urgency in Higgins of passing through traffic through the new node before final 

verification is performed. See Ex. Ans. at 1 1. This section of Higgins states: 

After both neighbor nodes... have simultaneously looped back their 
ports, the physical connection of the new node 6d into the network 
12 can take place. The new node 6d must be prepared, however, 
for entry into an active inter-nodal network. It is desired that the 
new node 6d operate as if it had always been part of the network 
12. 

However, the Examiner's argument takes the above quoted passage out of 

context. Specifically, the Examiner seems to ignore the subsequent paragraph 

in Higgins (col. 9, lines 44-52), which states: 

Accordingly, in order to accomplish this, the new node 6d is 
programmed... to follow a special sequence of states until it is in a 
running state and the network is ready to include it. More 
specifically, FIG. 8 is a state transition diagram illustrating the 
states in which the new node 6d will remain while both it and the 
network 12 are prepared for its addition thereto, (col. 9, lines 43- 
52; emphasis added) 

Thus, according to Higgins, the new node 6d will only be prepared to for entry 
into the active inter-nodal network when it is in the RUNNING state, i.e., after 
the sequence of Fig, 8 is completed. Id, This occurs only after the new node 6d 
has received final verification and is enabled to come into service, including 
making connections to other nodes. See col. 30, lines 30-45. 

Accordingly, there is no teaching or suggestion in Higgins of passing any 
network traffic through the inter-nodal network during the process in which 
the new node 6d is brought into service and the neighbor nodes 5a and 6c are 
returned to open mode. 
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C. HIGGINS'S NEW NODE DOES NOT PASS THOUGH ATM TRAFFIC 
BEFORE ITS CONNECTIONS ARE ESTABLISHED 

Hence, Appellant submits that Higgins fails to disclose that a node 
operates as a pass through for traffic before its connections are set up, as 
asserted by the Examiner in Paper No. 6 at page 2, second paragraph. As such, 
the Examiner has failed to provide a teaching in the cited art of operating a 
node as a pass through for ATM traffic before a virtual path is established for 
the node, as required by independent claims 1, 14, and 24. 



(2) CHAN DOES NOT TEACH DETERMINING THAT A NODE HAS FAILED 
OR REMOVING THE FAILED NODE 

Independent claim 12 includes the following limitations (with emphasis 
added) : 

• "determining that a node has failed," 

• "tearing down virtual circuit connections directed to or initiating 
from the failed node," 

• "tearing down virtual paths assigned to the failed node, and" 

• "providing instructions to other nodes to update ring topology 
information to indicate that the failed node is removed from 
the ring" 

Thus, claim 12 requires (1) specifically determining that a node has failed, and 
(2) removing the node, which is determined to have failed, by tearing down its 
associated virtual circuit (VC) connections and virtual paths (VPs).^ 



^ As noted by the Examiner, Appellant mistakenly asserted that claim 12 recites "determining, at a ring hub node, 
that a node has failed" (See Appeal Brief at 23). The relevant portion of claim 12 actually recites "determining that a 
node has failed." Appellant respectfully submits that this mistake was the result of importing language from the 
amendment of claim 12, in the Reply Under 37 CFR 1.116 filed on May 11, 2004, which was not entered by the 
Examiner. Appellant respectfully submits that this mistake was inadvertent. Furthermore, it is respectfully submitted 
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A. CHAN DOES NOT DISTINGUISH BETWEEN NODE FAILURES AND PATH 
FAILURES 

The Examiner argues that Chan clearly discloses the detection of a failed 

node, as opposed to detecting a path failure (Ex. Ans. at 14), citing coL 14, 

lines 55-57. The cited section of Chan discloses: 

Second, when there is a complete SONET switch module failure 
1100, such as the complete failure of the DAS#4 1263.. .All links 
into and out of the DAS#4 126 are treated as failed. When the 
DAS#4 fails, the DAS#rs SONET_N card 950 detects 1110 the 
failure and notifies the downstream nodes on the CCW ring 162. 
The DAS#3 124 SONET_S card 930 also detects 1130 the failure 
and notifies 1140 the downstream nodes on the CW ring 160 
(emphasis added) 

However, the above quoted portion of Chan does not clearly disclose that 
a failed node can be detected and distinguished from the failure of one or more 
paths. Quite the opposite, this section of Chan discloses that when a complete 
node failure occurs, the situation will be treated as if all of the ingoing and 
outgoing links to the node have failed. Chan discloses that such a failure 
(not "failed node") will be communicated to other nodes downstream in each 
direction. 



Accordingly, the above portion of Chan teaches that when a complete 
node failure occurs, a failure will be detected. Chan further discloses that this 
failure will not be distinguished from a situation where all of the incoming and 
outgoing paths from the node have failed (regardless of how rare this situation 



that the same arguments in the Appeal Brief in connection with claim 12 apply equally to the actual language 
contained therein. 

^ As pointed out by the Examiner (Ex. Ans. at 14), Chan discloses that the DAS's are referred to 
as SONET nodes (col. 7, lines 54-55). 
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would be). Thus, Chan does not teach "detecting that a node has failed" as 
required by claim 12. 

B. CHAN DOES NOT REMOVE A NODE IN RESPONSE TO ANY DETECTED 
FAILURE 

In support of the argument that Chan detects and removes a failed node, 
the Examiner argues that claims 1 and 9 claims the protection of virtual path 
(VP) connections by deleting a node {see Ex. Ans. at 14). Specifically, the 
Examiner argues that claim 1 recites the step of "protecting said VP 
connections by an Intra-Ring Communication protocol," and that dependent 
claim 9 recites that the protecting step of claim 1 includes "deleting one of said 
SONET VPR nodes from the SONET UPSR." See Ex. Ans. at 14. 

In Chan, the protection switch for VPs includes implementation of an 

Intra-Ring Communication (IRC) protocol (col. 5, lines 66-57). Chan describes 

the IRC protocol in col. 5, lines 5-10, as follows: 

The IRC protocol includes the following functions: assigning 
logical sequential numbering of nodes on the ring; adding/ deleting 
a node to/ from the ring; notifying other nodes on the ring when 
either a SONET or an ATM failure has been detected; and notifying 
other line cards in the node when failure occurs. 

As such, Chan teaches that the adding/ deleting of a node is a separate 
function of the IRC protocol than the failure detection. Furthermore, Chan's 
detailed description describes the adding and deleting of nodes (in col. 8, line 
56 - col. 9, line 51) as having no particular logical connection to the detecting 
and communicating failures (described in col. 9, line 52 - col. 10, line 27). 
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Specifically, Appellant respectfully submits that Chan does not teach or 
suggest that a detected failure results in deletion of a node. 

Thus, the recitation in claim 9 that the protecting step includes "adding 
an additional SONET VPR node" and "deleting one of said SONET VPR nodes" 
(col. 17, lines 23-28) merely refers to Chan's protection includes an IRC 
communication protocol that has the functions of adding and deleting nodes. 
See col. 15, lines 53-53, which recites "protecting said VP connections by an 
Intra-Ring Communications Protocol." 

However, the Examiner's argument seems to suggest that claim 9 should 
be interpreted as claiming that a node is deleted in response to a detected 
failure. Based on this logic, Chan would also disclose that adding a node is a 
suitable response to a detected failure because claim 9 recites that the 
"protecting step comprises at least one of adding.. .and deleting [a node]" {see 
col. 17, lines 23-25). Appellant submits that nothing in Chan describes how 
adding a node would be an appropriate response to a detected failure. 

Accordingly, Chan fails to teach or suggest deleting or removing a node 
(by tearing down VPs and VCs, or otherwise) in response to a detected failure. 

C. CHAN DOES NOT INSTRUCT OTHER NODES THAT THE FAILED NODE 
HAS BEEN REMOVED 

The Examiner further argues that Chan teaches the claimed feature of 
providing instructions to other nodes to update ring topology information to 
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indicate that a failed node is removed, citing col. 9, lines 16-19 {see Ex. Ans. at 
14). 

In col. 9, lines 16-19, Chan states that "the updating of LUTs is 
accomplished so that previously configured VPs... are eliminated if destined for 
a deleted SONET node" However, claim 12 requires that the updated ring 
topology information indicate that a failed node is removed from a ring. As 
discussed above, there is simply no teaching or suggestion in Chan of either 
detecting a failed node, or removing a node in response to a detected failure. 
The above quoted portion of Chan only refers to the fact Chan's IRC protocol 
can be used to delete a node, in response to which the LUTs are updated. 

Thus, Chan's updated LUTs do not indicate removal of a failed node is 
removed, as required by claim 12. 

(3) CONCLUSION 

For the reasons advanced above, it is respectfully submitted that all the 
claims in this application are allowable. Thus, favorable reconsideration and 
reversal of the Examiner's Final Rejection of claims 1-29 by the Honorable 
Board of Patent Appeals and Interferences, is respectfully requested. 
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If necessary, the Commissioner is hereby authorized in this, concurrent, 
and future replies to charge payment or credit any overpayment to Deposit 
Account No. 02-2448 for any additional fees required under 37 C.F.R, §§ 1.16 
or 1.17; particularly, extension of time fees. 

Very truly yours, 

BIRCH, STEWART, KOLASCH 86 BIRCH 
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